Transaction systems have been around for decades and typically use a two-phase commit protocol to achieve atomicity between participants. In particular, a transaction typically satisfies the properties of Atomicity, Consistency, Isolation and Durability, known commonly as the ACID properties. According to the Atomicity property, either the transaction successfully executes to completion, and the effects of all operations are recorded, or the transaction fails. In other words, all of the participants either commit the transaction or all of them roll it back (cancel the transaction). The Consistency property requires that the transaction does not violate integrity constraints of shared objects of the transaction. The Isolation property requires that intermediate effects of the transaction are not detectable to concurrent transactions. Finally, the Durability property requires that changes to shared objects due to the transaction are permanent.
To achieve the Atomicity property, all participants of the transaction coordinate their actions so that they either unanimously abort or unanimously commit to the transaction. Under the two-phase commit protocol, the transaction system performs the commit operation in two phases. During the first phase of the two-phase commit protocol, commonly known as the “prepare phase” or “request phase”, a coordinator (a node in the computing system managing the transaction) asks all participants of the transaction whether they are willing to commit to the transaction. During the second phase of the two-phase commit protocol, commonly known as the “commit/abort phase”, the coordinator determines whether the transaction should be completed. If during the prepare phase all participants committed to the transaction, the coordinator successfully completes the transaction. If during the prepare phase one or more participants failed to commit to the transaction, the coordinator does not complete the transaction.
In some cases resource managers may not be two-phase aware, which means they cannot prepare (go into a holding state and wait to make state changes). In such cases, these resource managers may be one-phase commit resource managers and can either do the work (state changes) or not do the work. It may be beneficial to enlist resource managers that are not two-phase aware into a two-phase commit transaction. In an example, a single resource manager that is one-phase aware (e.g., can only commit or roll back, with no prepare) may be enlisted in a two-phase transaction. In such an example, the coordinator may treat the one-phase commit resource manager slightly differently, in that it executes the prepare phase on all other resource managers first, and if the coordinator then intends to commit the transaction the coordinator passes control to the one-phase commit resource manager. The transaction may have a single Last Resource Commit optimization (LRCO) slot, in which a single one-phase commit resource manager may be inserted. If the one-phase commit resource manager commits, then the coordinator logs the decision to commit and attempts to commit the other resource managers as well. The use of LRCO, however, is limited to transactions having a single participant that is one-phase aware.